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1  Introduction 

1.1  Objective 

The  Design  Description  for  the  TEAM  program  describes  the  structure  and  behavior  of  the  components  in 
the  system  and  their  interrelationships  and  principles.  The  TEAM  program  is  broken  into  two  spirals. 

This  document  describes  the  design  for  Spiral  1 ,  which  focuses  on  mission  planning.  Spiral  2  focuses  on 
mission  execution.  The  design  will  also  be  updated  in  Spiral  2  and  there  will  be  revisions  to  this 
document. 

1.2  Program  Overview 

1.2.1  Background 

The  improvised  explosive  devices  in  land  warfare  serve  as  a  reminder  of  the  asymmetric  threat  posed  by 
mines  in  general.  The  sea  lines  of  communication  are  threatened  by  mines  just  as  land  lines.  In  addition, 
adversaries  can  deny  forces  entry  to  coastal  regions.  These  regions  are  often  in  the  littorals  requiring 
shallow  draft  vessels  to  defend  them.  To  face  this  threat,  the  new  Littoral  Combat  Ship  (LCS)  will  be  able 
to  be  equipped  with  a  mine  countermeasures  (MCM)  mission  module. 

Like  the  land  mine  problem,  the  sea  mine  problem  is  a  difficult  one.  Mines  can  be  found  in  various 
regions  of  the  water  column,  and  these  regions  present  different  challenges  to  the  tasks  of  searching  for 
and  neutralizing  mines.  As  such,  various  assets  are  utilized  in  these  challenges,  air  and  sea,  manned 
and  unmanned. 

Currently  there  is  minimal  coordination  between  air  and  sea  assets  and  between  manned  and  unmanned 
assets.  Yet  these  assets  play  vital  and  complementary  roles  in  the  MCM  problem.  What  coordination 
there  is  takes  place  in  between  sorties.  This  means  that  they  cannot  compensate  for  contingencies  that 
take  place  during  sorties.  This  may  lead  to  losses  in  mission  effectiveness. 

Furthermore,  each  asset  has  its  own  command  and  control  systems  and  personnel  with  specialized  skills. 
This  can  lead  to  inefficiencies  in  the  already  challenging  workload  aboard  the  LCS. 

Lockheed  Martin  performed  preliminary  analyses  of  improvements  in  mission  performance  by  employing 
the  TEAM  concepts.  In  those  analyses,  there  was  a  substantial  reduction  in  time  to  first  neutralization 
utilizing  2  unmanned  vehicles  and  a  manned  helicopter  versus  a  helicopter  independently.  Furthermore, 
the  analysis  of  multiple  helicopters  teaming  for  an  upper  water  column  mission  showed  a  substantial 
reduction  in  time  to  first  neutralization  and  a  substantial  increase  in  the  number  of  mines  neutralized.  The 
analyses  also  indicated  a  potential  decrease  in  workload  through  the  use  of  common  command  and 
control  enabling  better  load  balancing  across  operators. 

In  these  analyses,  various  simplifying  assumptions  were  made.  If,  however,  even  a  fraction  of  the 
improvements  indicated  can  be  realized,  this  represents  a  great  opportunity  for  improving  mission 
effectiveness  in  the  MCM  mission.  Although  this  effort  is  currently  limited  to  a  single  LCS,  the  analyses 
indicate  greater  improvements  with  multiple  LCSs. 

1.2.2  Program  Description 

One  of  the  critical  issues  for  Mine  Countermeasures  (MCM)  missions  aboard  the  LCS  is  the  simultaneous 
management  of  multi-vehicle  (both  manned  and  unmanned)  teams.  Optimizing  tactical  performance  of  a 
limited  crew  by  reducing  workload  requirements  across  all  mission  phases  (pre-launch,  launch,  transit  to 
operations  area,  execution,  recovery,  and  post-recovery)  is  currently  not  feasible  since  each  platform 
generally  maintains  its  own  management  and  control  solution  (a  vehicle-centric  approach).  Two  key 
methods  to  reduce  LCS  MCM  workload  through  advanced  mission  management  technologies  are:  (1 ) 
Increase  the  autonomy  of  specific  tasks  currently  done  by  human  operators,  and  (2)  Standardize  mission 
management  functions  across  all  vehicle  types  and  mission  segments  to  reduce  the  need  for  skill 
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specialization.  As  such,  the  main  objective  to  meet  the  requirements  of  future  LCS  missions  is  to  change 
from  a  vehicle-centric  to  a  mission-centric  paradigm  (Figure  1). 


Figure  1  Management  of  Manned  and  Unmanned  Assets  in  Teams 


Mission  centric  planning  means  optimizing  over  multiple  vehicles  and  multiple  objectives.  Automated 
decision  aids  are  helpful  in  this.  Mission  centric  execution  means  doing  so  during  mission  execution. 
Automated  decision  aids  are  essential  for  this. 

Mission  execution  includes  replanning  in  the  face  of  the  unexpected.  Loss  of  subsystems  or  entire 
assets,  discoveries  about  the  environment  and  enemy  actions  can  break  the  best  plan.  TEAM  seeks  to 
recover  from  these  by  incorporating  the  mission  planning  process  in  the  mission  monitoring  process 
transforming  it  from  a  passive  to  an  active  process. 

The  objective  of  this  phase  of  the  TEAM  program  is  to  demonstrate  technologies  that  can  plan  and 
execute  mine  countermeasures  missions  using  the  various  assets  available  to  it.  TEAM  seeks  to 
combine  these  technologies  using  an  open  standard  methodology  to  enhance  configurability  and 
extensibility.  Finally,  it  seeks  to  plan  the  transition  of  these  technologies  to  the  fleet. 
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3  Design  Description 
3.1  Context 

TEAM  exists  in  the  context  of  other  LCS  and  mine  hunting  components.  These  are  illustrated  in  Figure  2. 


AN/AES-1  (ALMDS)  AN/AWS-2  (RAMICS) 
OASIS 


Figure  2  Context  of  TEAM  with  other  LCS  and  Mine  Hunting  Components 

Like  the  land  mine  problem,  the  sea  mine  problem  is  a  difficult  one.  Mines  can  be  found  in  various 
regions  of  the  water  column,  and  these  regions  present  different  challenges  to  the  tasks  of  searching  for 
and  neutralizing  mines.  As  such,  various  assets  are  utilized  in  these  challenges.  The  MH-60S  is  a  key 
platform  in  the  MCM  challenge  and  will  be  utilized  on  the  LCS.  The  Airborne  Mine  Countermeasures 
(AMCM)  program  is  implementing  the  employment  of  five  MCM  systems,  the  AQS-20A  towed  sonar 
array,  the  Airborne  Laser  Mine  Detection  System  (ALMDS),  the  Airborne  Mine  Neutralization  System 
(AMNS),  the  Rapid  Airborne  Mine  Clearance  System  (RAMICS),  and  the  Organic  Airborne  and  Surface 
Influence  Sweep  (OASIS),  on  the  MH-60S. 

In  addition,  there  are  various  surface  and  subsurface  unmanned  vehicles  deployed  or  in  development  to 
address  this  problem.  Of  particular  note  is  the  Remote  Minehunting  System  (RMS),  the  AN/WLD-1(V)1, 
featuring  the  Remote  Multi-Mission  Vehicle  (RMMV),  a  semisubmersible  unmanned  vehicle  capable  of 
towing  a  variable  depth  sonar  (VDS),  the  AN/AQS-20.  There  is  also  the  Battle  space  Preparation 
Unmanned  Autonomous  Vehicle  (BPAUV)  and  the  Vertical  Take-off  and  landing  Unmanned  Aerial 
Vehicle  (VTUAV). 

Analysis  of  the  battle  space  and  planning  the  MCM  missions  is  performed  with  the  assistance  of  the  Mine 
Warfare  and  Environmental  Decision  Aids  Library  (MEDAL).  Missions  for  the  various  assets  are 
generated  and  distributed  to  them  for  detailed  mission  planning.  After  hunting  missions  have  been 
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completed,  data  is  collected  for  post  mission  analysis  (PMA)  after  which  MEDAL  is  utilized  to  generate 
new  missions,  searching,  identifying,  neutralizing,  or  sweeping. 

Furthermore,  programs  under  development,  like  Supervision  of  Unmanned  Mission  Management  by 
Interactive  Teams  (SUMMIT)  and  Commander’s  Estimate  of  the  Situation  (CES)  can  provide  benefit  to 
and  can  benefit  from  TEAM  capabilities. 

TEAM  infrastructure  and  services  are  targeted  to  be  part  of  the  next  generation  MCM  ecosystem.  The 
services  and  planning  capability  provide  a  solid  foundation  upon  which  future  mission  capability  can  be 
built. 

3.2  Architecture 
3.2.1  Approach 

In  general,  TEAM’S  architecture  is  Service  Oriented  Architecture  (SOA).  Newly  developed  code,  legacy 
code,  third  party  code,  and  future  code  can  be  wrapped  by  service  interfaces  (Integration  Application 
Programming  Interface  [API])  that  communicate  via  a  service  bus.  This  is  illustrated  in  Figure  3. 


Figure  3  Example  Service  Composition 

These  services  in  their  simplest  form  are  quite  useful,  but  their  real  power  is  revealed  when  they  can  be 
used  to  perform  more-complex  processes.  Work  has  been  under  way  for  years  to  develop  the 
technologies  and  standards  that  would  support  such  a  requirement.  BPEL  has  emerged  as  the  de-facto 
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standard.  Where  appropriate  mission  processes  are  represented  as  BPEL-compliant  processes  in 
TEAM.  These  processes  emphasize  orchestration  of  services  whereas  the  services  provide  atomic 
functions. 

Figure  4  shows  a  simple  example  workflow  where  an  application  sends  data  to  a  service,  which  performs 
a  function  and  then  sends  processed  data  to  the  same  or  other  application.  In  addition,  the  application 
may  be  an  aggregate  service,  a  service  consisting  of  other  services,  a  construct  for  many  applications 
that  provides  convenience  without  disrupting  reusability  and  configurability  of  the  constituent  services. 


Process  Step 


Service 

Implementations 


Figure  4  Example  Simple  Workflow 

This  approach  is  applied  to  the  context  of  Figure  2  in  a  demonstration  environment  and  Figure  5 
emerges.  In  Figure  5  TEAM  is  divided  into  groups  of  services  for  convenience.  Note  that  Figure  5  shows 
the  grand  vision  for  the  entire  program  and  beyond,  not  limited  to  Spiral  1 .  As  a  result,  not  all  services 
shown  are  described  later  in  this  document.  For  example,  the  MEDAL  services  are  displayed  as  they  are 
expected  from  the  forthcoming  MEDAL  EA  effort.  This,  too,  is  beyond  the  scope  of  this  work,  but  is 
included  here  as  an  example.  Spiral  1  focuses  on  mission  planning,  so  services  in  the  Collaborative 
Mission  Planning  section  as  well  as  the  Human  Machine  Interface  (HMI)  are  described. 

In  Figure  5,  the  supporting  services  shown  below  the  Enterprise  Service  Bus  are  not  part  of  TEAM. 

These  services  are  used  to  provide  the  necessary  infrastructure  to  support  the  TEAM.  For  example, 
vehicle  and  sensor  services  provide  handles  to  avatars  in  the  demonstration  environment.  While  these 
might  become  handles  to  vehicles  in  a  deployed  system,  this  is  beyond  the  scope  of  this  work. 

The  enterprise  service  bus  itself  is  not  part  of  the  system  per  se.  While  an  ESB  is  used  to  demonstrate 
TEAM  services,  no  assumption  is  made  that  this  is  the  service  that  will  forever  be  used.  It  is  intentionally 
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so  to  force  compliance  to  standards.  It  also  enables  the  government  to  utilize  the  ESB  of  its  choice. 
While  this  is  unlikely  to  result  in  zero  effort  to  accommodate,  the  effort  is  anticipated  to  be  much  lower 
than  if  TEAM  were  tightly  coupled  to  a  particular  ESB. 

The  MEDAL  services  are  displayed  as  they  are  expected  from  the  forthcoming  MEDAL  EA  effort.  While 
this  is  not  part  of  this  effort,  it  is  targeted  to  be  accommodated.  Furthermore,  other  efforts  are  shown  as 
able  to  expand,  but  such  expansion  is  beyond  scope. 
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Figure  5  Representative  TEAM  and  Supporting  Services 

3.2.2  Integration  Infrastructure 

This  infrastructure  in  Figure  6  enables  the  integration  of  services  through  the  introduction  of  a  reliable  set 
of  capabilities,  such  as  intelligent  routing  of  data  and  control  flow,  protocol  mediation  so  that  services 
need  not  implement  the  details  of  the  protocol,  rules  management  to  ease  configurability  and  tailoring  of 
logic,  and  process  engine  to  make  to  whole  system  come  together. 

The  use  of  third  party,  standards-based  software  facilitates  openness.  This  openness  enables  future 
users  can  substitute  other  developed  or  third  party  solutions  to  suit  their  needs. 
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Figure  6  Integration  Infrastructure 

While  the  ESB  is  beyond  the  scope  of  the  TEAM  program,  the  Mule®  service  bus  is  utilized  as  a  reference 
bus  in  lieu  of  a  government  selected  bus.  In  addition  to  Mule®,  a  number  of  open  source  solutions  are 
also  utilized  as  references  in  place  of  government  selected  solutions.  Neither  these  nor  Mule®  are 
deliverable,  but  the  government  may  opt  to  use  them  if  it  so  chooses.  jBPM,  java  Business  Process 
Management,  is  used  as  a  reference  workflow  engine.  This  provides  a  programmatic  method  for  design 
and  execution  of  workflows.  Data  is  managed  using  PostgreSQL  with  PostGIS  providing  geographic  data 
management  on  top  of  it.  GeoServer  is  an  open  source  service  for  publishing  and  editing  georeferenced 
data  providing  Web  Map  Service  (WMS),  Web  Coverage  Service  (WCS),  and  Web  Feature  Service 
(WFS).  Because  these  interfaces  are  not  always  necessary  and  desirable,  Hibernate/Hibernate  Spatial  is 
also  used  for  providing  these  data.  Finally,  Drools  is  targeted  as  the  rules  engine. 

By  embracing  open  standards  (such  as  JSR-94,  a  rules  engine  API,  and  UCORE,  a  data  format  standard 
already  embraced  by  some  government  agencies)  and  not  assuming  a  particular  solution,  the  program 
intends  to  be  compatible  with  whatever  solutions  the  government  brings  to  bear  for  these  issues.  In 
addition,  it  facilitates  additional  functional  solutions  the  government  chooses  to  use  in  the  future. 

3.3  Software  Component  Descriptions 
3.3.1  Collaborative  Mission  Planning 

Collaborative  mission  planning  is  tasked  with  converting  mission  objectives  into  an  actionable  plan  across 
team  assets.  It  takes  geometry  and  performance  parameters  from  MEDAL  and  decomposes  those  into 
tasks  to  be  performed  by  available  individual  vehicles.  For  example,  TEAM  might  be  issued  a  bottom 
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mine  hunt  task  in  area  A  and  a  neutralization  task  for  surface  targets  Mike-1 ,  and  Mike-2  also  in  area  A. 

In  this  case,  tracks  for  RMMV  uniform  coverage  might  be  developed  and  divided  into  one  set  of  tracks  for 
each  RMMV,  while  neutralization  tasks  (transit,  reacquire,  neutralize)  might  be  developed  for  the  MH- 
60S.  The  MH-60S  might  even  be  assigned  tasks  to  refit  with  AQS-20  and  some  of  the  hunt  tracks.  The 
tracks  might  be  scheduled  to  perform  those  most  distant  from  Mike-1  and  Mike-2  first  in  order  to  minimize 
risk  to  the  assets.  Accounting  for  the  vehicles’  characteristics  (e.g.  effective  at  needed  depth)  and  the 
operating  parameters,  it  then  schedules  those  tasks  to  the  vehicles  performing  them.  Given  that  schedule 
and  the  vehicles’  mobility  parameters,  it  then  generates  routes  for  the  vehicles.  Figure  7  shows  an 
overview  of  the  data  flow  and  centers  of  processing  that  are  used  to  accomplish  this. 


Figure  7  Collaborative  Mission  Planning  Overview 
3.3.2  Contingency  Management 

Contingency  Management’s  task  is  to  monitor  the  situation  and  the  progress  of  the  mission  and  decide 
when  a  plan  modification  is  necessary.  Most  of  this  functionality  is  utilized  in  Spiral  2,  but  it  is  important  to 
consider  the  approach  during  Spiral  1 . 
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Figure  8  Contingency  Management  Overview 

3.3.3  Human  Machine  Interface 

The  Human  Machine  Interface  (HMI)  serves  as  the  exclusive  interaction  with  the  operator.  It  provides  a 
tactical  situation  display  on  which  geographic  information  appears.  Overlaid  on  the  tactical  situation 
display  appear  objective  geometries  and  routes.  Also  appearing  in  the  HMI  in  information  on  the 
available  vehicles  and  scheduling  information  on  tasks.  From  here  the  operator  has  the  ability  to  display 
information  on  these  items  and  the  ability  to  accept  or  edit  data  such  as  waypoints. 
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Figure  9  HMI  Context 

3.3.4  Situational  Assessment 

Situational  Assessment  is  deferred  to  Spiral  2. 

3.4  Service  Descriptions 

3.4.1  Asset  Allocation/Scheduling  Service 

This  service  assigns  assets  to  tasks  and  schedules  those  tasks  for  the  assets.  It  takes  a  mission 
specification  and  decomposes  it  into  task  specifications.  Continuing  the  previous  example,  given  two 
RMMVs  and  a  MH-60S  each  with  an  AQS-20,  the  tracks  might  be  allocated  evenly  across  those  vehicles, 
allocated  according  to  their  endurance  and  speed  capabilities,  or  allocated  to  the  RMMVs  with  the  MH- 
60S  held  in  reserve  with  a  neutralizer  package. 

It  assigns  and  schedules  tasks  to  assets,  adding  deconfliction  constraints  to  the  tasks  specifications  and 
applying  task  templates  as  appropriate.  Continuing  the  example,  an  AQS-20  search  task  may  require  an 
alignment  task  preceding  and  following  it  constituting  additional  scheduling  constraints.  In  addition,  the 
first  such  task  may  require  a  streaming  task  preceding  the  alignment  task  and  the  last  such  task  a  sensor 
recovery  task  following  the  alignment  task.  These  tasks  would  be  added  to  the  hunt  task  scheduled  to 
proceed  and  follow  it. 

Deconfliction  constraint  examples  include  ensuring  that  search  tasks  by  one  vehicle  maintain  a  standoff 
distance  from  a  neutralization  task  and  ensuring  that  transit  tasks  by  two  different  vehicles  be  separated 
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temporally.  Thus,  in  the  example,  RMMV  1  might  be  launched  a  period  of  time  before  RMMV  2  to  ensure 
a  minimum  separation  in  space.  In  addition,  its  first  track  might  be  the  track  most  distant  from  RMMV  2’s 
first  track.  In  contrast,  there  need  be  no  delay  between  RMMV  Ts  launch  and  MH-60’s  launch  because 
there  is  no  risk  of  collision. 

3.4.2  Environmental  Data  Access  Service 

This  service  maintains  information  about  environmental  data.  This  is  represented  as  gridded  data.  Data 
can  be  requested  at  a  specified  point  or  a  specified  grid.  Supported  data  types  are  bottom  depth  and 
bottom  type.  Data  may  not  be  available  for  some  or  all  of  these  types  and  a  subset  of  the  requested 
region.  If  the  data  are  available,  they  are  returned  for  the  requested  region. 

3.4.3  External  Tasking  Translator 

This  serves  as  the  interface  to  tasking  applications  beyond  the  system  boundary.  In  particular,  this  is 
intended  to  receive  MEDAL  information  and  convert  it  to  the  internal  representation,  decoupling  the 
external  tasking  representations  from  the  internal  representation. 

3.4.4  Human  Machine  Interface 

The  Human  Machine  Interface  (HMI)  provides  the  sole  interaction  with  operators.  It  displays 
environmental  data.  Supported  environmental  data  include  bathymetry  and  bottom  type.  It  displays 
mission  objective  geometry  and  accepts  operator  changes  to  it.  It  displays  vehicle  status  information.  It 
displays  task  schedule  information  and  accepts  operator  changes  to  the  tasks.  Supported  changes 
include  vehicle  assignment.  It  displays  vehicle  route  information  and  accepts  operator  changes  to  it. 
Supported  changes  include  waypoint  addition,  deletion,  or  movement.  It  also  displays  alerts  when  a  plan 
is  infeasible,  when  the  mission  objectives  cannot  be  achieved  with  the  assets  available,  when  the  task 
schedule  is  infeasible,  when  the  routes  are  infeasible. 

3.4.5  Image/Video  Service 

This  service  manages  collections  of  images  and  video.  For  demonstration  purposes,  this  provides 
simulated  snippets  and  video  for  viewing  by  the  operator.  In  a  deployed  system,  it  might  be  used  for 
reference  materials  or  to  review  previously  collected  images  or  video.  This  service  is  a  Spiral  2  artifact. 

3.4.6  MENSA  Administrator 

Mission  Effectiveness  and  Safety  Assessment  (MENSA)  is  a  legacy  system  for  monitoring  and  assessing 
situation  data.  The  MENSA  Administrator  offers  a  framework  for  an  extensible  set  of  monitoring  and 
assessment  agents. 

3.4.6.1  Objective  Monitor  Agent 

This  function  monitors  changes  in  mission  objectives  and  determines  when  the  plan  needs  to  be  changed 
to  accomplish  the  given  objectives. 

3.4.7  Mine  Contact  Data  Access  Service 

This  service  accepts,  manages  and  provides  data  on  contacts.  Contacts  are  spot  reports  of  entities  that 
may  or  may  not  be  objects  of  interest.  In  particular,  they  may  be  mine  like  echo  contacts  (MILECs),  mine 
like  objects  (MILCOs),  or  mines  of  different  types. 

The  service  definition  provides  for  operations  for  requesting  all  contacts  in  a  specified  region  and  for  a 
specific  contact.  In  addition,  they  are  made  available  through  publish/subscribe.  Furthermore,  it  provides 
operations  for  adding  and  modifying  contacts. 

3.4.8  Mine  Threat  Assessment  Service 

This  service  maintains  data  about  mine  threats.  This  is  not  information  about  a  particular  mine  or  mine 
like  object,  but  information  about  a  type  of  mine.  Supported  information  includes  operating  characteristics 
such  as  minimum  and  maximum  case  depth,  physical  characteristics  such  as  mine  case  size  and  shape, 
countermeasures  type,  and  mine  class.  The  service  provides  these  data,  if  available,  upon  request. 
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3.4.9  Mission  Planning  Service 

This  service  is  a  composite  service  that  guides  data  though  other  services.  In  particular,  this  takes 
mission  objectives  and  guides  them  through  the  task  scheduling  and  route  planning  services  to  produce 
comprehensive  mission  plans. 

3.4.10  Operational  Mix  Assessment  Service 

This  service  finds  the  feasible  vehicle/task  pairings.  It  takes  in  objectives  and  an  available  vehicle  list 
with  asset  capabilities  and  matches  vehicles  to  objectives. 

3.4.11  Plan  Dissemination  Service 

This  service  provides  plans  to  interested  parties  beyond  the  system  boundaries,  decoupling  those  parties’ 
plan  representations  from  the  internal  plan  representation.  It  provides  Common  Route  Definition  format 
documents  for  use  by  JMPS  and  vehicle  formats  for  dissemination  to  vehicles.  For  demonstration 
proposes,  this  is  a  simple  interface.  In  a  deployed  system,  this  might  be  a  JAUS  compliant  interface. 
While  this  service  is  a  Spiral  2  artifact,  it  is  useful  to  consider  in  Spiral  1  design. 

3.4.12  Vehicle  State  Data  Access  Service 

This  service  maintains  status  information  about  assets.  The  information  schema  is  an  extension  of 
UCORE,  leveraging  many  of  the  data  structures  defined  there.  It  extends  UCORE  by  adding  information 
about  subsystems  such  as  engines  and  optional  sensors  or  neutralizers.  The  service  provides  these 
data,  if  available,  upon  request.  In  the  future,  the  information  will  be  updated  based  on  communications 
from  the  assets. 

3.4.13  Route  Planning  Service 

This  service  plans  routes  between  scheduled  tasks  for  an  asset.  It  respects  spatial  and  temporal 
constraints  in  the  given  task  specifications  and  the  performance  capabilities  of  the  given  asset. 

3.4.14  Track  Service 

This  service  maintains  information  on  objects  in  the  battle  space.  These  include  friendly,  unfriendly, 
unaffiliated,  and  obstacle  objects.  The  service  provides  these  data,  if  available,  upon  request. 

3.4.15  Uniform  Coverage  Planning  Service 

This  service  decomposes  mission-level  objectives  into  tasks  to  be  performed  by  assets.  For  example,  an 
objective  to  hunt  in  a  given  area  of  mines  to  a  given  clearance  level  might  be  decomposed  into  a  number 
of  tracks  to  be  traversed  by  an  AQS-20  sensor  at  given  speed  and  depth.  It  wraps  the  legacy  UCPLAN 
functionality. 

3.4.16  Vehicle  Class  Data  Access  Service 

This  service  maintains  information  about  assets.  This  is  not  state  data,  but  rather  static  performance  data 
such  as  maximum  speed.  It  also  includes  information  about  what  subsystems  can  be  employed  by  the 
asset.  The  service  provides  these  data,  if  available,  upon  request. 

3.4.17  Vehicle  Management  Service 

This  service  maintains  information  on  what  vehicles  (not  vehicle  classes)  are  available. 

3.5  Data  Models  and  Management 

TEAM  leverages  community  of  interest  and  industry  adopted  schemas. 

It  is  based  on  UCORE,  a  universal  core  data  schema  that  enables  information  sharing  with  ways  to 
describe  “what,  when,  where,  who”  types  of  information  using  a  minimal  set  of  terms  in  the  core,  agreed 
to  by  DoD  and  intelligence  community  and  extensible  by  communities  of  interest  and  systems  as  needed. 
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Figure  10  UCORE  Based  Data  Hierarchy 

UCORE  makes  heavy  use  of  other  common  standards,  including  Geography  Markup  Language  (GML),  a 
XML  grammar  defined  by  Open  Geospatial  Consortium,  Inc.  ®  (OGC)  to  express  geographical  features 
used  for  representing  geospatial  data  as  well  as  an  interchange  for  format  for  that  data. 

3.6  Behaviors 

This  section  describes  the  behaviors  of  the  TEAM  system  for  the  Spiral  1  demonstration. 

3.6.1  Use  Cases 

Use  cases  are  a  useful  way  of  describing  the  fundamental  ways  in  which  a  system  interacts  with  its  users 
and  environment.  Figure  1 1  shows  the  use  cases  identified  for  Spiral  1 .  There  is  at  least  one  activity 
diagram  associated  with  each  use  case  in  the  following  sections. 

Activity  diagrams  are  a  useful  tool  for  showing  behavior  between  and  within  system  components.  Each 
swim  lane  in  an  activity  diagram  represents  a  component  in  the  system  and  each  line  between  swim 
lanes  represents  an  interface.  Otherwise,  they  look  much  like  convention  flow  charts. 
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Figure  11  Use  Case  Diagram 
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3.6.2  Mission  Change 

Figure  12  shows  the  sequence  of  events  that  take  place  when  a  mission  change  is  received.  The  change  may  come  from  the  network  (representing  higher  command 
authority).  Alternately,  it  may  come  from  the  operator  station. 

Mission  objectives  arrive  from  the  network  actor  and  are  translated  into  an  internal  representation  including  geometries  and  task  types  to  be  performed  within  those 
geometries  as  well  as  mission  constraints  such  as  restricted  areas.  These  can  be  reviewed  by  the  Operator  in  a  separate  use  case.  These  objectives  are  validated 
(checked  against  any  constraints).  Validated  objectives  are  then  checked  against  the  current  plan  to  see  if  they  can  be  accommodated  without  change.  If  not, 
planning  proceeds. 
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Figure  12  Mission  Change  Activity  Diagram 
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3.6.3  Review  Mission 

This  use  case  permits  the  Operator  to  review  and  alter  objectives  (Figure  13).  This  may  be  arrived  at  through  a  change  in  objectives,  the  discovery  of  invalid 
objectives,  or  the  infeasibility  of  the  objectives  given  constraints  later  in  the  planning  process  (e.g.  availability  of  assets). 

If  it  was  arrived  at  from  a  change  in  objectives,  the  Operator  may  have  configured  the  system  to  proceed  without  Operator  intervention.  This  behavior  is  useful  for 
testing  later  behaviors.  Otherwise  the  human  machine  interface’s  state  is  set  and  the  Operator  is  presented  with  the  objectives.  If  he  or  she  makes  changes,  the 
revised  objectives  are  sent  back  and  handled  in  the  Mission  Change  use  case.  In  any  case,  state  is  reset  before  proceeding. 

Figure  14  shows  a  representative  screenshot  of  the  Operator’s  view  during  this  use  case. 
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Figure  13  Review  Mission  Activity  Diagram 
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Figure  14  Representative  Review  Mission  Screenshot 
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3.6.4  Schedule  Tasks 

Figure  15  shows  the  process  for  defining  the  mission  schedule.  Given  the  objectives,  information  is  gathered  about  the  current  situation  (e.g.  constraints  on  vehicle 
availability  and  on  their  capabilities,  environment  constraints  on  the  objectives  and  the  vehicle  capabilities  [e.g.  bottom  type  may  render  vehicle  hunting  capabilities 
ineffective  for  certain  regions],  known  mine  like  echo  contacts,  mine  like  objects  and  mines  [these  may  be  the  targets  of  tasks  or  objects  to  avoid  for  other  tasks]). 

Given  these  conditions,  the  system  develops  the  vehicle-task  pairings.  If  tasks  require  uniform  coverage  planning,  that  is  invoked  for  each  of  the  pairings.  Each  of 
the  resulting  tracks  may  be  considered  a  task  to  be  scheduled  along  with  identification  and  neutralization  tasks.  Additional  scheduling  constraints  are  added  (e.g. 
launch  windows  and  arrival  windows  to  avoid  collisions)  and  the  tasks  are  scheduled  if  feasible.  Of  course,  it  is  entirely  possible  that  the  problem  is  over  constrained 
such  that  no  solution  is  feasible.  In  this  case,  the  results  are  sent  back  for  mission  review.  Otherwise,  they  are  sent  for  schedule  review  and  route  planning. 
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Figure  15  Schedule  Tasks  Activity  Diagram 
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3.6.5  Review  Task  Schedule 

Figure  16  shows  the  activities  in  the  Review  Task  use  case.  Here  the  Operator  is  given  an  opportunity  to  review  and  alter  the  developed  vehicle  task  schedule.  This 
can  be  reached  as  a  result  of  a  new  scheduling  case,  discovery  of  an  invalid  schedule,  or  an  infeasible  schedule  discovered  during  routing. 

Like  the  Mission  Review  use  case  activity  diagram,  state  is  set  upon  entry  and  reset  upon  exit.  Also,  the  Operator  may  have  set  the  system  to  proceed  without 
intervention,  in  which  case  this  process  is  exited.  Otherwise  the  Operator  is  presented  with  the  derived  schedule  and  may  accept  or  alter  it.  If  it  is  altered,  it  is 
validated.  If  the  validation  fails,  the  Operator  is  presented  with  the  schedule  for  revision. 

Figure  1 7  shows  a  representative  screenshot  of  the  Operator’s  view  during  this  process. 
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Figure  16  Review  Task  Schedule  Activity  Diagram 
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Figure  17  Representative  Review  Scheduie  Screenshot 
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3.6.6  Plan  Routes 

Figure  18  shows  the  activities  in  the  Plan  Routes  use  case.  Routes  are  planned  for  assigned  vehicle  to  traverse  between  tasks  in  schedule  order  conforming  to 
constraints  in  the  task  specification.  If  routes  are  infeasible,  they  are  sent  back  for  the  Operator  to  relax  constraints.  Otherwise  the  mission  plan  is  compiled  and 
stored. 
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Figure  18  Plan  Routes  Activity  Diagram 
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3.6.7  Review  Mission  Plan 

Figure  19  shows  the  activities  involved  in  reviewing  the  routes  developed  by  the  system.  This  process  may  be  reached  by  the  development  of  new  routes.  The 
process  is  similar  to  other  review  use  cases  in  that  state  is  set  upon  entry,  and  reset  upon  exit,  the  Operator  may  opt  out  of  review,  review,  or  change,  any  changed 
are  checked  for  validity  and  presented  to  the  Operator  if  invalid.  In  addition,  this  activity  diagram  shows  the  ability  to  display  routes  in  the  Joint  Mission  Planning 
System  (JMPS)  to  show  interoperability  with  a  legacy  system  as  well  as  the  ability  to  work  with  other  operator  interfaces  in  general. 

Figure  20  shows  a  representative  screenshot  of  the  Operator’s  view  during  this  process. 
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Figure  19  Review  Mission  Plan  Activity  Diagram 
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Figure  20  Representative  Route  Review  Screenshot 
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3.6.8  Review  Assets 

Figure  21  shows  the  activities  in  the  Review  Assets  use  case.  This  is  a  fairly  straightforward  case  in  which,  on  demand,  data  are  collected  and  displayed  to  the 
Operator. 

Figure  22  shows  a  representative  screen  of  the  Operator’s  view  of  this  (with  the  relevant  data  highlighted). 


Page  35  of  39 


Title:  Design  Description  For  Team-Based  Execution  Of  Autonomous 
Missions  (TEAM),  Spiral  1 

Doc.  #: 

Version:  1.0 

Date:  November  18,  2008 


LaCKHEEO  ATAirriJV 


Figure  21  Review  Assets  Activity  Diagram 


Figure  22  Representative  Screenshot  (Focus  on  Asset  Display) 
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Figure  23  Data  Model  Overview 


3.7  Simulation  Environment 

While  not  part  of  the  design,  it  is  useful  to  be  aware  of  the  intent  of  the  simulation  environment  in  which 
this  design  is  expected  to  operate. 

Figure  24  shows  additional  detail  for  the  vehicle  and  sensor  simulation.  Note  that  some  of  these  items 
are  beyond  scope,  but  expect  to  be  incorporated  under  synergistic  investment.  In  general,  there  are 
vehicular  models  that  convert  route  plans  to  DIS  packets.  These  packets  are  used  by  the  JSAF 
environment  to  update  the  positions  of  the  vehicles.  JSAF  maintains  a  unified  model  of  the  true  state  of 
the  simulation  and  provides  DIS  packets  with  those.  These  are  converted  to  GML  moving  object  for  use 
by  the  sensor  models  to  provide  TEAM  with  sensor  reports  and  state  reports. 
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Figure  24  Simulation  Environment 
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Glossary 


Term 

Description 

ALMDS 

AN/AES-1  Airborne  Laser  Mine  Detection  System 

AMNS 

AN/ASQ-235  Airborne  Mine  Neutralization  System 

API 

Application  Programming  Interface 

AQS-20A 

Towed  Sonar  Array  (VDS) 

ATR 

Automatic  Target  Recognition 

BPUAV 

Battlespace  Preparation  Underwater  Autonomous  Vehicle 

CAD/CAC 

Computer-Automated  Detection/Classification 

CES 

Commander’s  Estimate  of  the  Situation 

COI 

Community  of  Interest 

COT 

Cursor  on  Target 

CRD 

Common  Route  Definition 

DIS 

Distributed  Interactive  Simulation 

DoD 

Department  of  Defense 

EOID 

Electro-Optic  Identification 

ESB 

Enterprise  Service  Bus 

GCCS-M 

Global  Command  and  Control  System  -  Maritime 

GML 

Geography  Markup  Language 

HMI 

Human  Machine  Interface 

JAUS 

Joint  Architecture  for  Unmanned  Systems 

jBPM 

Java  Business  Process  Management 

JSAF 

Joint  Semi-Automated  Forces 

JMPS 

Joint  Mission  Planning  System 

LCS 

Littoral  Combat  Ship 

LM 

Lockheed  Martin 

MCM 

Mine  Countermeasures 

MEDAL 

Mine  Warfare  and  Environmental  Decision  Aids  Library 

MENSA 

Mission  Effectiveness  and  Safety  Assessment 

MH-60S 

Naval  Helicopter 

MILCO 

Mine  Like  Object 

MILEC 

Mine  Like  Echo  Contact 

MIW 

Mine  Warfare 
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Term 

Description 

MIWC 

Mine  Warfare  Commander 

MLO 

Mine  Like  Object 

NCA 

National  Command  Authority 

OASIS 

AN/ALQ-220  Organic  Airborne  and  Surface  Influence  Sweep 

OGC 

Open  Geospatial  Consortium,  Inc.® 

PMA 

Post  Mission  Analysis 

RAM  ICS 

AN/AWS-1  Rapid  Airborne  Mine  Clearance  System 

RMMV 

AN/WLD-1(V)1  Remote  Multi-Mission  Vehicle 

RMS 

Remote  Minehunting  System 

SOA 

Service  Oriented  Architecture 

SUMMIT 

Supervision  of  Unmanned  Mission  Management  by  Interactive  Teams 

TEAM 

Team-Based  Execution  of  Autonomous  Missions 

UCD 

Use  Case  Diagram 

UCORE 

Universal  Core 

USW 

Undersea  Warfare 

UPC 

Unique  Planning  Component  (JMPS) 

USCC 

Unmanned  System  Common  Controller 

VDS 

Variable  Depth  Sonar  (AQS-20) 

VSS 

Volume  Search  Sonar 

VTUAV 

Vertical  Take-off  and  Landing  Unmanned  Aerial  Vehicle 

WCS 

Web  Coverage  Service 

WPS 

Web  Feature  Service 

WMS 

Web  Map  Service 
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